home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_1599 / 1496 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  2.8 KB
  1. Date: Sun, 29 May 94 00:20 CDT
  2. From: ekl@sdf.lonestar.org (Evan K. Langlois)
  3. To: mint@atari.archive.umich.edu
  4. Subject: Re: Just a couple of things
  5.  
  6.  
  7. ========================================================================
  8. 1. some easy (quick) way to detect a running ACSI/SCSI/IDE transfer,
  9. at least those that go to sleep...  so have all drivers set some common
  10. flag, maybe different bits for each port?  IO_SINGLE then can be &flag
  11. ========================================================================
  12.  
  13. The easiest common flag would be to use flock @ 0x0043e since this 
  14. location is already set aside as a semaphore for accessing DMA registers.
  15. This should give MiNT some extra compatibility, in case something access
  16. the DMA without going through MiNT - it =SHOULD= check here.
  17.  
  18. When set, MiNT should put the process to sleep, otherwise start-up a DMA
  19. transfer for the driver.  When the interrupt goes off, remove the waiting
  20. process from its queue and clear "flock".  Then check and see if another
  21. process was put to sleep during the transfer and should take care of it.
  22. I'm assuming that only parts of MiNT would be semaphore locked during
  23. the transfer, and that you could still use fread/fwrite for console
  24. IO and such, right?
  25.  
  26. ========================================================================
  27. 2. some good way to check for `systemcall came from inside GEM', any
  28. ideas? :)  ditto for how to hook into trap #2, i once read GEM likes to
  29. throw you out there...
  30. ========================================================================
  31.  
  32. Hmm .. well, we don't need this if it was the ROM AES that started the
  33. transfer, since it will be the AES process that gets put to sleep, not
  34. the user app, well, the user's app will too since its waiting on the AES.
  35. So we don't need to lock that. 
  36.  
  37. Here is a quick hack that will work.  Look at the return address.  It gets
  38. put on some stack somewhere.  If the return address points into ROM (either
  39. of the ROM locations, anything from 0x00e00000 - 0x00ffffffff or the
  40. same with the high byte 0xff since that area shadows the others.  So, if
  41. the call is from the ROM, then we can set a flag of some sort.  This
  42. also blocks the ROM desktop calls, in addition to VDI/AES, but I can't
  43. think of any other way.
  44.  
  45. ========================================================================
  46. 3. are there already devices (/dev) that call disk drivers and so would
  47. go to sleep too?  they might need changes too.  or should devices also
  48. get a `multithreaded' bit...
  49. ========================================================================
  50.  
  51. No, I don't think so.  Hmm .. nope.
  52.  
  53. ========================================================================
  54. 4. anything else i forgot?
  55. ========================================================================
  56.  
  57. I don't know.  Are you forgetting anything?
  58.  
  59.  
  60.